Stefano, I now realize what the problem is with the comma. The Tifinagh script has a separator character that I learned was used like a comma, so I mapped it to the Latin comma. Unfortunately, The languages that use Tifinagh script also use regular Latin punctuation marks, so I will need to map the special Tifinagh separator to something unique in the Latin script—perhaps the Latin comma with a double underscore (\u0333). The other thing you mentioned, the possible problem with other characters, is a a font problem. Combinations of Tifinagh characters with combining characters aren’t displaying correctly in MS Excel. The underlying character values are correct, fortunately. I will fix the mapping of the Tifinagh separator and send you a new “tifinagh_generic.yml” file as well as test data. Randy

Stefano,I know it’s an odd combination to have a combining low line under (after) a comma, but the order is dictated by Unicode. Combining characters are supposed to be encoded AFTER the character that they modify. If combining low line is encoded first it would be interpreted as modifying any character that preceded it, which is NOT the intent for this script. In MARC, a combining character is used to differentiate spacing character, like an alphabetic letter or some spacing mark, to be related but different. A similar case is the uppercase soft or hard sign, both of which are normally romanized to the same spacing marks prime or double prime, respectively. In order to map the uppercase Cyrillic letters to something unique and reversible, I used the double low line after the prime or double prime. Does this make my use of the combining low line after the Latin comma make more sense as a unique combination that maps to the special Tifinagh separator?I hope I’m not missing something here. In my testing, Tifinagh strings with either the normal Latin comma or the special Tifinagh separator convert as I expect: comma stays a comma, even when appearing in Tifinagh script, and comma+combining low line converts to the special Tifinagh separator. Uses of the script are not consistent. From what I’ve read, they sometimes use the special separator to end sections of text. It could be though of as various Latin punctuation marks but seems closest to a comma, so I mapped it to comma+combining low line. I could have mapped it to period+combining low line. I even considered mapping it to the solidus “/“ (forward slash mark), but it is most often used interchangeably with a comma.Randy Barry - ᠷᠧᠨᠳᠢ ***@***.***>On Apr 19, 2026, at 11:52, Stefano Cossu ***@***.***> wrote:scossu left a comment (lcnetdev/scriptshifter#292) @RandyBarry Just to confirm, currently my terminal (but I think it's a common behavior) the sequence \u002C\u0332 displays a simple comma + the combining underscore, which underscores the following character, not the comma. You are referring to an underlined comma, so I wonder if you intended to use \u0332\u002C (combined underlined comma) in the transliteration table. If the transliteration table is correct, then I have to adjust the test strings so that "ⵉⵎⴷⴰⵏⴻⵏ⵰ ⴰⴽⴽⴻⵏ" transliterates to "Imdanen, ̲ akken". —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

Stefano, It’s difficult to verify conversion problems due to the alignment of the error markers in the test log. I understand why it looks like there are conversion errors. I will need to segregate the situations which are being flagged as errors to get around this problem. The issue is this: in the ALA-LC romanization tables, there are options for how three Tifinagh letters are transliterated. Those options are handled in the roman-to-script mapping by providing two different Latin transliterations . Each of these three Tifinagh letters can be romanized in two ways. A perfect example is the Tifinagh letter “ⵐ” which can be transliterated as “ŋ” or “n̳”. The first option is a new Unicode Latin character which was never used in MARC before. The Unicode character “ŋ” is now the preferred romanization for “ⵐ” but librarians can use the other option if their local system doesn’t support “ŋ” yet. The new letter was used in the new ALA-LC Romanization Table with the assumption that, any system that can support Tifinagh script should be able to support the Latin character “ŋ”. I tend to agree. ScriptShifter needs to know what to do with either the new or old-style romanizations that make use of new Latin characters. The problem is when ScriptShifter does script-to-roman conversion of data that included both options in Latin. ScriptShifter only has one mapping to Latin for each Tifinagh characters. For “ⵐ”, where in the Latin input file there were two different representations of “ⵐ”, there is only one Latin transliteration output; “ŋ (ŋ)”. The “(n̳)” originally seen has been replaced with “(ŋ)”. I put parentheses around the alternative romanizations so that I could see what happened to them when they passed thru ScriptShifter in a roundtrip way. What you are seeing in the test confirms that ScriptShifter is actually handling these optional transliterations properly. Where you see “ə (ə)” and “ŋ (ŋ)” and “ɣ (ɣ)” in Latin output that started out as “ə (e̳)”, “ŋ (n̳)” and “ɣ (g̳)”, there are cases where Tifinagh letters had the two Latin transliteration options. There’s no way to tell ScriptShifter to output the old (less-desirable) romanization with the double low line under the regular Latin letter. What I could do is put optional transliterations like this in a separate test line and flag it as roman-to-script only. That way they would not confuse the otherwise good conversion results. A test string with: ə (e̳) ŋ (n̳) ɣ (g̳) would convert to ⵓ (ⵓ) ⵐ (ⵐ) ⵘ (ⵘ). The reverse would be (correctly!): ə (ə) ŋ (ŋ) ɣ (ɣ) Does this make sense? In my own testing, I knew where these one-way conversions were, so I ignored the differences. I used the parentheses in the Tamasheq test data to flag them as special but didn’t bother with the parentheses in the two other test sets. I should have but the parentheses around the alternative romanizations in all three test sets to flag these as letters as special in romanization, or I should have separated them out onto a separate test line. I’m sorry I added this confusion to the test data. The bottom line is, the conversions are working fine. I can send you revised test data to separate out the alternatives onto separate lines, if you want. Randy